fix(txpool): restore age-based future eviction - #686

Reviewed with the specific goal of confirming this restores the original upstream future-queue logic rather than writing a new age-based policy.

Upstream comparison — exact match confirmed

I extracted enforce_limits from four revisions and diffed them:

So the future-eviction fold is not a re-derivation — it is the upstream code, character for character, in the repo's own formatting. The revert is complete: nothing of b51fa56d's priority-first fold survives, and the intermediate future-queue fixes (98105919, 601b567b, 91e3a7bb) are untouched.

Correctness of the security argument

Confirmed in-tree rather than taken on faith:

• runtime/src/lib.rs:192 includes pallet_transaction_payment::ChargeTransactionPayment, so validation priority is tip-derived, and a nonce-gapped transaction never dispatches — the advertised tip is never charged. Priority on a future transaction is therefore free to fabricate.
• client/transaction-pool/src/graph/validated_pool.rs bans everything eviction removes (self.rotator.ban(&Instant::now(), removed.iter().copied())).

Together those make priority-first future eviction strictly worse than age-based: an attacker pins the queue at zero cost and gets every honest future transaction banned for ban_time. Age-based eviction doesn't make future-queue flooding free — an attacker can still push out older entries — but it costs them continuous spam and ages out their own entries too. Right call, and the PR description's framing of the tradeoff is accurate.

Checks

• cargo test -p sc-transaction-pool --lib graph::base_pool — 19 passed, 0 failed, including future_limit_enforcement_evicts_oldest_first.
• cargo +nightly fmt -p sc-transaction-pool -- --check — clean.
• use std::cmp::Ordering (line 23) is still live: the ready-queue fold at lines 509–517 uses it. No dead import, so no -D warnings risk.

Notes (non-blocking)

1. base_pool.rs:487-488 — doc comment now diverges from upstream. Upstream says "lowest priority first or those that occupy the pool for the longest time in case priority is the same," which describes only the ready queue and was never true of the future queue. The replacement is more accurate. It's the one intentional deviation and it adds a small merge-conflict surface on the next vendor refresh; I'd keep it — accuracy wins.

2. Consider anchoring the rationale in the code. This policy has now flipped twice (b51fa56d → this PR), and after the revert nothing in the file records why age-based is deliberate. The next reader sees the same "age-only eviction looks exploitable" shape that motivated b51fa56d. A one-line reference to Immunefi #90496 would prevent a repeat — best placed in the doc comment above (already divergent from upstream) rather than inside the fold, so the restored block stays byte-identical to upstream.

3. base_pool.rs:1465 — test comment reads backwards. "Priority must not allow an old future transaction to remain pinned in the pool" is hard to parse against the assertion that the old tx is evicted. Something like "high priority must not exempt an older future tx from age-based eviction" states what's being tested. Trivial.

Verdict: LGTM

The eviction logic is provably the pre-tip-change upstream code, the revert is complete and self-consistent, and the test correctly discriminates age-based from priority-based behavior (the older transaction is the higher-priority one, so it only passes under age-first). Only the three cosmetic notes above; none block merge.